home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 237 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: new T[0] and sizeof(T)
  5. Date: 2 Feb 1996 15:49:05 GMT
  6. Organization: Computer Science, University of Melbourne, Australia
  7. Sender: news@cs.mu.OZ.AU (CS-Usenet)
  8. Approved: clamage@eng.sun.com (comp.std.c++)
  9. Message-ID: <9603318.21879@mulga.cs.mu.OZ.AU>
  10. References: <1996Feb1.091641.4676@iiasa.ac.at>
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. Originator: clamage@taumet
  13.  
  14. marek@iiasa.ac.at (Marek  MAKOWSKI) writes:
  15.  
  16. >I would like to ask for comments on three easy questions illustrated 
  17. >by the following piece of code:
  18. > 
  19. >template <class I, class T>
  20. >void mVect<I,T>::resize(I new_size) {
  21. >   T *old = v;
  22. >   v = new T[new_size];    // T *v is a private member of mVect  
  23. >   int size_of_elem = sizeof(T);    // <--- question 3 
  24. >   // 
  25. >   // do something 
  26. >   // 
  27. >   delete[] old;     // <--- questions 1 & 2 
  28. >} 
  29. > 
  30. >I have the following questions:
  31. >1. Is it absolutely robust and portable to delete[] old, even
  32. >   if a previous call was for new_size == 0 (or if v was allocated
  33. >   by the ctor for the size == 0) ?
  34.  
  35. The code
  36.  
  37.     T *old = new T[0];
  38.     delete [] old;
  39.  
  40. is definitely perfectly legal (strictly conforming).
  41.  
  42. Whether or not it is in practice portable is another question -- that
  43. is something that can only be determined empirically.
  44.  
  45. >    In other words: is it guaranteed that:
  46. >   (v = new T[0]) == 0;
  47.  
  48. No, after 'v = new T[0]', it is guaranteed that `v' is *not* a null pointer.
  49.  
  50. >2. Is it correct to assume that no destructor is called by this statement
  51. >    if old was set as: old = new T[0]  ??
  52.  
  53. Yes.
  54.  
  55. >3. Is there any risk involved in using sizeof(T) in this statement ?
  56.  
  57. Basically no, but of course that would depend on what you used it for.
  58.  
  59. >The Watcom code blows-up on the delete[] statement (if a previous
  60. >call was for new_size == 0)
  61.  
  62. If what you have described is correct, then it sounds like a Watcom bug to me.
  63. (However, I suspect there is a good chance that there is a bug somewhere
  64. in the parts of your code that you haven't shown us.)
  65.  
  66. >and gives a warning whenever it sees the sizeof(T).
  67.  
  68. Compilers are allowed to warn about anything they like;
  69. however I don't see why warning about `sizeof(T)' would be useful.
  70.  
  71. >If the answer for quaestions 1 and 2 is negative then I would like to
  72. >know the reason why the standard does not require new to return 0
  73. >for zero_size array of objects.
  74.  
  75. Well, an array of size zero is conceptually different to no array at all.
  76.  
  77. >If there is a good reason for allowing new to return "anything" in such
  78. >situations then one should add to every ctor setting a ptr to 0
  79. >(which indeed made the Watcom version of my application running).
  80.  
  81. --
  82. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  83. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  84.  
  85. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  86.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  87.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  88. ]
  89.